灵魂拷问二：敏捷是研发效能提升的银弹吗？
我们来继续讨论“软件研发效能五大灵魂拷问”的第二问：敏捷是研发效能提升的银弹吗？敏捷在这里指的是敏捷开发模式。
组件模型、UML、RUP之父Ivar Jacobson不甘心失败，2005年推出精简统一过程（Essential Unified Process，EssUP），但两年后，他喊出““Enough of Processes, let’s do practices ”，叫停新过程，而认为应该交流实践。
其实，EssUP慎重地集成了来自RUP阵营、敏捷阵营、过程改进（如CMMI）阵营的成功实践，但我可以肯定地说：今天正在从事软件研发的绝大多数人员都不知道EssUP。
瀑布模型、V模型、RUP、MSF、CMMI、EssUP都没能成为银弹，你相信敏捷会成为银弹吗？
我也敢肯定说：你不相信敏捷是银弹！
正在做的“国内软件质量”调查，目前初步结果显示，有32.4%的团队在实施敏捷，偏敏捷的自定义开发模式占28.9%，两者加起来超过60%，大多数团队都在搞敏捷，但效率提高了吗？程序猿——你幸福了吗？
也不能说实施敏捷之后效率没有提高，但效率提高不够。另外，效能不等于效率。
对于什么是研发效能，目前大家的认知没有完全统一。正好利用这个机会好好梳理一下“效能”的含义。
效能不等于效率，否则没有必要造出一个新词，
其实，“效能”也不是新词，出现在2000多年前的战国时代——著名的哲学家、齐国人尹文在《尹文子·大道上》中写到“庆赏刑罚，君事也；守职效能，臣业也。君料功黜陟，故有庆赏刑罚；臣各慎所任，故有守职效能。”两次提到“效能”，但这里的效能，其主要含义是尽职尽责。真正接近今天我们所谈的含义是瞿秋白在《财神还是反财神》中“他们是在‘提倡’，更加有理由叫工人‘增加生产效能’”。
效能的含义更接近效益、生产力，有人认为：
效能 = 效率 + 赋能 效能= 效率 + 工程能力
似乎对，似乎也不对，那我们看看大厂是如何定义“效能”的？毕竟阿里、腾讯、京东等大厂都成立了效能部门，对软件研发效能研究比较多，它们的定义值得我们借鉴。
阿里的观点：效能的本质是对价值流动速度和质量的评价，而价值流动过程可以表示为“价值原料在可被度量的价值加工活动之间有序传递，不断叠加价值增量，最终形成可被消费的价值产物”，其度量可以抽象为“效能度量的元模型”
腾讯的观点：效能等于生产力 （productivity）
效能 = 速度 + 质量 + 吞吐率
京东的观点：研发效能度量指标分为三个维度，分别是交付效率、交付质量和交付能力。
虽然各有不同，但从中也可以看出，效能关注效率，更关注最终有效的产出，即价值的交付，而价值包含了质量，交付的价值越高，客户越满意，也就意味着质量越高。在今天DevOps时代，我们也关心价值能持续交付，越能持续交付就越能体现产出的能力、产出的稳定性。 因此，效能就是软件研发交付能力和效果，而效果体现在所交付的价值大小和速度。
敏捷开发是一种思想或方法论，通过不断迭代开发和增量发布，最终交付符合用户价值的产品。由此可见，敏捷开发本身的目标并不是提升研发效能，而是持续交付价值给客户。但从另一方面来说，目前客户期望的交付速度越来越快，尤其是互联网企业，于是，持续交付往往演变成：研发团队要持续加快交付速度。如果研发效能比较差，肯定做不到持续交付；能做到持续交付的团队，研发效能也一定要高才行。
在精益软件开发中有个湖水岩石效应的经典隐喻，水位代表库存多少，岩石代表问题。水位高的时候，岩石就会被隐藏，即库存多时，设备运转不良、上一环节输出的质量差、停工等待、供应不及时等问题都会被掩盖起来。如果是精益或敏捷开发模式，在制品快速流动，同时限制在制品的数量，没有了临时库存的缓冲，就会出现“水落石出”的局面：生产或开发中的瓶颈都会一一暴露出来。这和目前大家在讨论研发效能时经常说的“谷仓效应”或“竖井效应”很类似。研发效能提升的关键当然在于找到研发过程中瓶颈，或者是上下游之间的衔接配合问题；或者是某个环节本身的效率问题。从这一点上来说，敏捷有助于暴露团队中研发效能的瓶颈，研发效能的提升有助于敏捷开发最终实现交付价值给客户的目标。
之所以这世界上还没有提升研发效能的银弹，也在于每个团队遇到的问题和瓶颈都是不同的，产品不一样，人不一样，环境不一样，别人造出的银弹并不能成为你的银弹。拥抱变化，根据上下文分析解决自己的问题，借鉴他人优秀实践，然后吃自己的狗粮，造自己的银弹，敏捷和研发效能才能够互相促进。
推荐阅读